Browserbeveiliging: Een diepgaande analyse van Content Security Policy (CSP)

In de huidige webomgeving is beveiliging van het grootste belang. Websites worden constant geconfronteerd met een spervuur van potentiële aanvallen, waaronder cross-site scripting (XSS), data-injectie en clickjacking. Een van de meest effectieve verdedigingen tegen deze bedreigingen is Content Security Policy (CSP). Dit artikel biedt een uitgebreide gids voor CSP, waarin de voordelen, implementatie en best practices voor het beveiligen van uw webapplicaties worden onderzocht.

Wat is Content Security Policy (CSP)?

Content Security Policy (CSP) is een extra beveiligingslaag die helpt bij het detecteren en beperken van bepaalde soorten aanvallen, waaronder Cross-Site Scripting (XSS) en data-injectieaanvallen. Deze aanvallen worden gebruikt voor alles van datadiefstal en het bekladden van sites tot de verspreiding van malware.

CSP is in wezen een witte lijst die de browser vertelt welke bronnen van inhoud als veilig worden beschouwd om te laden. Door een strikt beleid te definiëren, instrueert u de browser om alle inhoud van bronnen die niet expliciet zijn goedgekeurd te negeren, waardoor veel XSS-aanvallen effectief worden geneutraliseerd.

Waarom is CSP belangrijk?

CSP biedt verschillende cruciale voordelen:

• Beperkt XSS-aanvallen: Door de bronnen te controleren waarvandaan de browser inhoud kan laden, vermindert CSP het risico op XSS-aanvallen drastisch.
• Vermindert kwetsbaarheden voor clickjacking: CSP kan helpen clickjacking-aanvallen te voorkomen door te bepalen hoe een website kan worden ingesloten in een frame.
• Dwingt HTTPS af: CSP kan ervoor zorgen dat alle bronnen via HTTPS worden geladen, waardoor man-in-the-middle-aanvallen worden voorkomen.
• Vermindert de impact van niet-vertrouwde inhoud: Zelfs als er op de een of andere manier niet-vertrouwde inhoud in uw pagina wordt geïnjecteerd, kan CSP voorkomen dat schadelijke scripts worden uitgevoerd.
• Biedt rapportage: CSP kan worden geconfigureerd om overtredingen te rapporteren, zodat u uw beveiligingsbeleid kunt bewaken en verfijnen.

Hoe werkt CSP?

CSP werkt door een HTTP-response-header of een <meta>-tag aan uw webpagina's toe te voegen. Deze header/tag definieert een beleid dat de browser moet handhaven bij het laden van bronnen. Het beleid bestaat uit een reeks richtlijnen, die elk de toegestane bronnen voor een bepaald type bron specificeren (bijv. scripts, stylesheets, afbeeldingen, lettertypen).

De browser handhaaft dit beleid vervolgens door alle bronnen te blokkeren die niet overeenkomen met de toegestane bronnen. Wanneer een overtreding plaatsvindt, kan de browser dit optioneel rapporteren aan een opgegeven URL.

CSP-richtlijnen: Een uitgebreid overzicht

CSP-richtlijnen vormen de kern van het beleid en definiëren de toegestane bronnen voor verschillende soorten bronnen. Hier is een overzicht van de meest voorkomende en essentiële richtlijnen:

• default-src: Deze richtlijn definieert de standaardbron voor alle resourcetypes die niet expliciet door andere richtlijnen worden gespecificeerd. Het is een goed startpunt voor een basis CSP-beleid. Als een specifiekere richtlijn zoals script-src is gedefinieerd, overschrijft deze de default-src-richtlijn voor scripts.
• script-src: Specificeert de toegestane bronnen voor JavaScript. Dit is een van de belangrijkste richtlijnen om XSS-aanvallen te voorkomen.
• style-src: Specificeert de toegestane bronnen voor CSS-stylesheets.
• img-src: Specificeert de toegestane bronnen voor afbeeldingen.
• font-src: Specificeert de toegestane bronnen voor lettertypen.
• media-src: Specificeert de toegestane bronnen voor <audio>-, <video>- en <track>-elementen.
• object-src: Specificeert de toegestane bronnen voor <object>-, <embed>- en <applet>-elementen. Let op: deze elementen zijn vaak een bron van beveiligingskwetsbaarheden en het wordt aanbevolen om dit indien mogelijk op 'none' in te stellen.
• frame-src: Specificeert de toegestane bronnen voor <iframe>-elementen.
• connect-src: Specificeert de toegestane bronnen voor XMLHttpRequest-, WebSocket- en EventSource-verbindingen. Dit is cruciaal om te bepalen waar uw website gegevens naartoe kan sturen.
• base-uri: Specificeert de toegestane basis-URL voor het document.
• form-action: Specificeert de toegestane URL's waarnaar formulieren kunnen worden verzonden.
• frame-ancestors: Specificeert de toegestane bronnen die de huidige pagina mogen insluiten in een <frame>, <iframe>, <object> of <applet>. Dit wordt gebruikt om clickjacking-aanvallen te voorkomen.
• upgrade-insecure-requests: Instrueert de browser om alle onveilige (HTTP) verzoeken automatisch te upgraden naar veilige (HTTPS) verzoeken. Dit is belangrijk om ervoor te zorgen dat alle gegevens veilig worden verzonden.
• block-all-mixed-content: Voorkomt dat de browser bronnen via HTTP laadt wanneer de pagina via HTTPS wordt geladen. Dit is een agressievere versie van upgrade-insecure-requests.
• report-uri: Specificeert een URL waarnaar de browser overtredingsrapporten moet sturen. Hiermee kunt u uw CSP-beleid bewaken en verfijnen. *Verouderd, vervangen door `report-to`*
• report-to: Specificeert een groepsnaam gedefinieerd in de `Report-To` HTTP-header, waarnaar de browser overtredingsrapporten moet sturen. Deze richtlijn vereist dat de `Report-To`-header correct is geconfigureerd.
• require-trusted-types-for: Schakelt Trusted Types in, een DOM API die helpt bij het voorkomen van DOM-gebaseerde XSS-kwetsbaarheden. Vereist specifieke Trusted Types-implementaties en -configuraties.
• trusted-types: Definieert een lijst van Trusted Types-beleidsregels die zijn toegestaan om sinks te creëren.

Sleutelwoorden voor bronnenlijsten

Naast URL's kunnen CSP-richtlijnen verschillende sleutelwoorden gebruiken om toegestane bronnen te definiëren:

• 'self': Staat inhoud van dezelfde oorsprong (schema en domein) als het beschermde document toe.
• 'unsafe-inline': Staat het gebruik van inline JavaScript en CSS toe. Wees uiterst voorzichtig bij het gebruik hiervan, aangezien het CSP aanzienlijk verzwakt en XSS-kwetsbaarheden opnieuw kan introduceren. Vermijd indien mogelijk.
• 'unsafe-eval': Staat het gebruik van dynamische JavaScript-evaluatiefuncties zoals eval() en Function() toe. Gebruik ook dit met de nodige voorzichtigheid, aangezien het CSP verzwakt. Overweeg alternatieven zoals template literals.
• 'unsafe-hashes': Staat specifieke inline event handlers toe, door hun SHA256-, SHA384- of SHA512-hashes op een witte lijst te plaatsen. Handig voor de overgang naar CSP zonder onmiddellijk alle inline event handlers te moeten herschrijven.
• 'none': Weigert inhoud van elke bron.
• 'strict-dynamic': Staat scripts die door vertrouwde scripts worden geladen toe om verdere scripts te laden, zelfs als die scripts normaal gesproken niet door het beleid zouden worden toegestaan. Handig voor moderne JavaScript-frameworks.
• 'report-sample': Instrueert de browser om een voorbeeld van de overtredende code op te nemen in het overtredingsrapport. Nuttig voor het debuggen van CSP-problemen.
• data:: Staat het laden van bronnen vanaf data: URL's toe (bijv. ingesloten afbeeldingen). Wees voorzichtig met het gebruik hiervan.
• mediastream:: Staat het laden van bronnen vanaf mediastream: URL's toe (bijv. webcam of microfoon).
• blob:: Staat het laden van bronnen vanaf blob: URL's toe (bijv. dynamisch gecreëerde objecten).
• filesystem:: Staat het laden van bronnen vanaf filesystem: URL's toe (bijv. toegang tot het lokale bestandssysteem).

CSP implementeren: Praktische voorbeelden

Er zijn twee primaire manieren om CSP te implementeren:

1. HTTP Response Header: Dit is de aanbevolen aanpak, omdat het meer flexibiliteit en controle biedt.
2. <meta> Tag: Dit is een eenvoudigere aanpak, maar heeft beperkingen (het kan bijvoorbeeld niet worden gebruikt met frame-ancestors).

Voorbeeld 1: HTTP Response Header

Om de CSP-header in te stellen, moet u uw webserver configureren (bijv. Apache, Nginx, IIS). De specifieke configuratie is afhankelijk van uw serversoftware.

Hier is een voorbeeld van een CSP-header:

Content-Security-Policy: default-src 'self'; script-src 'self' https://example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report

Uitleg:

• default-src 'self': Staat standaard bronnen van dezelfde oorsprong toe.
• script-src 'self' https://example.com: Staat JavaScript van dezelfde oorsprong en van https://example.com toe.
• style-src 'self' 'unsafe-inline': Staat CSS van dezelfde oorsprong en inline stijlen toe (wees voorzichtig met het gebruik).
• img-src 'self' data:: Staat afbeeldingen van dezelfde oorsprong en data-URL's toe.
• report-uri /csp-report: Stuurt overtredingsrapporten naar het /csp-report-eindpunt op uw server.

Voorbeeld 2: <meta> Tag

U kunt ook een <meta>-tag gebruiken om een CSP-beleid te definiëren:

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' https://example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:">

Let op: De <meta>-tag-aanpak heeft beperkingen. Het kan bijvoorbeeld niet worden gebruikt om de frame-ancestors-richtlijn te definiëren, wat belangrijk is om clickjacking-aanvallen te voorkomen.

CSP in 'report-only'-modus

Voordat u een CSP-beleid afdwingt, wordt het ten zeerste aanbevolen om het in 'report-only'-modus te testen. Hiermee kunt u overtredingen bewaken zonder bronnen te blokkeren.

Om de 'report-only'-modus in te schakelen, gebruikt u de Content-Security-Policy-Report-Only-header in plaats van Content-Security-Policy:

Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' https://example.com; report-uri /csp-report

In 'report-only'-modus stuurt de browser overtredingsrapporten naar de opgegeven URL, maar blokkeert geen bronnen. Hierdoor kunt u eventuele problemen met uw beleid identificeren en oplossen voordat u het afdwingt.

Het Report URI-eindpunt instellen

De report-uri-richtlijn (verouderd, gebruik `report-to`) specificeert een URL waarnaar de browser overtredingsrapporten moet sturen. U moet een eindpunt op uw server instellen om deze rapporten te ontvangen en te verwerken. Deze rapporten worden als JSON-gegevens verzonden in de body van een POST-verzoek.

Hier is een vereenvoudigd voorbeeld van hoe u CSP-rapporten in Node.js zou kunnen afhandelen:

const express = require('express');
const bodyParser = require('body-parser');
const app = express();
const port = 3000;

app.use(bodyParser.json({ type: 'application/csp-report' }));

app.post('/csp-report', (req, res) => {
 console.log('CSP-schendingsrapport:', JSON.stringify(req.body, null, 2));
 res.status(204).end(); // Reageer met een 204 No Content
});

app.listen(port, () => {
 console.log(`CSP-rapportageserver luistert op http://localhost:${port}`);
});

Deze code zet een eenvoudige server op die luistert naar POST-verzoeken op het /csp-report-eindpunt. Wanneer een rapport wordt ontvangen, wordt het rapport naar de console gelogd. In een echte toepassing zou u deze rapporten waarschijnlijk in een database willen opslaan voor analyse.

Bij gebruik van `report-to` moet u ook de `Report-To` HTTP-header configureren. Deze header definieert de rapportage-eindpunten en hun eigenschappen.

Report-To: {"group":"csp-endpoint","max_age":10886400,"endpoints":[{"url":"https://example.com/csp-report"}],"include_subdomains":true}

Vervolgens zou u in uw CSP-header gebruiken:

Content-Security-Policy: default-src 'self'; report-to csp-endpoint;

Best practices voor CSP

Hier zijn enkele best practices die u kunt volgen bij het implementeren van CSP:

• Begin met een strikt beleid: Begin met een restrictief beleid en versoepel het geleidelijk indien nodig. Dit helpt u om potentiële beveiligingskwetsbaarheden vroegtijdig te identificeren en aan te pakken.
• Gebruik nonces of hashes voor inline scripts en stijlen: Als u inline scripts of stijlen moet gebruiken, gebruik dan nonces (cryptografisch willekeurige waarden) of hashes om specifieke codeblokken op een witte lijst te zetten. Dit is veiliger dan het gebruik van 'unsafe-inline'.
• Vermijd 'unsafe-eval': De 'unsafe-eval'-richtlijn staat het gebruik van dynamische JavaScript-evaluatiefuncties toe, wat een groot veiligheidsrisico kan zijn. Vermijd het gebruik van deze richtlijn indien mogelijk. Overweeg het gebruik van template literals of andere alternatieven.
• Gebruik HTTPS voor alle bronnen: Zorg ervoor dat alle bronnen via HTTPS worden geladen om man-in-the-middle-aanvallen te voorkomen. Gebruik de upgrade-insecure-requests-richtlijn om onveilige verzoeken automatisch te upgraden.
• Bewaak en verfijn uw beleid: Bewaak regelmatig CSP-overtredingsrapporten en verfijn uw beleid indien nodig. Dit helpt u om eventuele problemen te identificeren en aan te pakken en ervoor te zorgen dat uw beleid effectief blijft.
• Overweeg een CSP-generator te gebruiken: Verschillende online tools kunnen u helpen bij het genereren van een CSP-beleid op basis van de vereisten van uw website. Deze tools kunnen het proces van het creëren van een sterk en effectief beleid vereenvoudigen.
• Test grondig: Voordat u uw CSP-beleid afdwingt, test het grondig in 'report-only'-modus om ervoor te zorgen dat het geen functionaliteit op uw website verbreekt.
• Gebruik een framework of bibliotheek: Sommige webontwikkelingsframeworks en -bibliotheken bieden ingebouwde ondersteuning voor CSP. Het gebruik van deze tools kan het proces van het implementeren en beheren van uw CSP-beleid vereenvoudigen.
• Wees u bewust van browsercompatibiliteit: CSP wordt ondersteund door de meeste moderne browsers, maar er kunnen enkele compatibiliteitsproblemen zijn met oudere browsers. Zorg ervoor dat u uw beleid in verschillende browsers test om te controleren of het werkt zoals verwacht.
• Informeer uw team: Zorg ervoor dat uw ontwikkelteam het belang van CSP en de juiste implementatie ervan begrijpt. Dit helpt ervoor te zorgen dat CSP correct wordt geïmplementeerd en onderhouden gedurende de hele ontwikkelingscyclus.

CSP en scripts van derden

Een van de grootste uitdagingen bij het implementeren van CSP is het omgaan met scripts van derden. Veel websites zijn afhankelijk van diensten van derden voor analyse, advertenties en andere functionaliteiten. Deze scripts kunnen beveiligingskwetsbaarheden introduceren als ze niet correct worden beheerd.

Hier zijn enkele tips voor het beheren van scripts van derden met CSP:

• Gebruik Subresource Integrity (SRI): Met SRI kunt u verifiëren dat scripts van derden niet zijn gemanipuleerd. Wanneer u een script van een derde partij opneemt, voeg dan het integrity-attribuut toe met de hash van het script. De browser zal dan controleren of het script overeenkomt met de hash voordat het wordt uitgevoerd.
• Host scripts van derden lokaal: Host indien mogelijk scripts van derden lokaal op uw eigen server. Dit geeft u meer controle over de scripts en vermindert het risico dat ze worden gecompromitteerd.
• Gebruik een Content Delivery Network (CDN) met CSP-ondersteuning: Sommige CDN's bieden ingebouwde ondersteuning voor CSP. Dit kan het proces van het implementeren en beheren van CSP voor scripts van derden vereenvoudigen.
• Beperk de machtigingen van scripts van derden: Gebruik CSP om de machtigingen van scripts van derden te beperken. U kunt bijvoorbeeld voorkomen dat ze toegang krijgen tot gevoelige gegevens of verzoeken doen naar niet-geautoriseerde domeinen.
• Controleer regelmatig scripts van derden: Controleer regelmatig de scripts van derden die u op uw website gebruikt om ervoor te zorgen dat ze nog steeds veilig en betrouwbaar zijn.

Geavanceerde CSP-technieken

Zodra u een basis-CSP-beleid hebt, kunt u enkele geavanceerde technieken verkennen om de beveiliging van uw website verder te verbeteren:

• Nonces gebruiken voor inline scripts en stijlen: Zoals eerder vermeld, zijn nonces cryptografisch willekeurige waarden die u kunt gebruiken om specifieke blokken inline code op een witte lijst te zetten. Om nonces te gebruiken, moet u voor elk verzoek een unieke nonce genereren en deze zowel in de CSP-header als in de inline code opnemen.
• Hashes gebruiken voor inline event handlers: De 'unsafe-hashes'-richtlijn stelt u in staat specifieke inline event handlers op een witte lijst te zetten op basis van hun SHA256-, SHA384- of SHA512-hashes. Dit kan handig zijn voor de overgang naar CSP zonder onmiddellijk alle inline event handlers te hoeven herschrijven.
• Trusted Types gebruiken: Trusted Types is een DOM API die helpt bij het voorkomen van DOM-gebaseerde XSS-kwetsbaarheden. Het stelt u in staat speciale soorten objecten te creëren die gegarandeerd veilig zijn voor gebruik in bepaalde contexten.
• Feature Policy gebruiken: Feature Policy (nu Permissions Policy) stelt u in staat te bepalen welke browserfuncties beschikbaar zijn voor uw website. Dit kan helpen bepaalde soorten aanvallen te voorkomen en de prestaties van uw website te verbeteren.
• Subresource Integrity (SRI) met fallback gebruiken: Combineer SRI met een fallback-mechanisme. Als de SRI-controle mislukt (bijv. de CDN is niet bereikbaar), zorg dan voor een reservekopie van de bron die op uw eigen server wordt gehost.
• Dynamische CSP-generatie: Genereer uw CSP dynamisch aan de serverzijde op basis van de sessie van de gebruiker, rollen of andere contextuele informatie.
• CSP en WebSockets: Wanneer u WebSockets gebruikt, configureer dan zorgvuldig de connect-src-richtlijn om alleen verbindingen met vertrouwde WebSocket-eindpunten toe te staan.

Globale overwegingen voor CSP-implementatie

Houd bij het implementeren van CSP voor een wereldwijd publiek rekening met het volgende:

• CDN-locaties: Zorg ervoor dat uw Content Delivery Network (CDN) servers heeft op meerdere geografische locaties om snelle en betrouwbare levering van inhoud aan gebruikers wereldwijd te garanderen. Controleer of uw CDN CSP ondersteunt en de benodigde headers kan verwerken.
• Globale regelgeving: Wees u bewust van regelgeving op het gebied van gegevensprivacy zoals de AVG (Europa), CCPA (Californië) en andere regionale wetten. Zorg ervoor dat uw CSP-implementatie voldoet aan deze voorschriften, vooral bij het verwerken van overtredingsrapporten.
• Lokalisatie: Overweeg hoe CSP van invloed kan zijn op gelokaliseerde inhoud. Als u verschillende scripts of stijlen hebt voor verschillende talen of regio's, zorg er dan voor dat uw CSP-beleid rekening houdt met deze variaties.
• Geïnternationaliseerde domeinnamen (IDN's): Als uw website IDN's gebruikt, zorg er dan voor dat uw CSP-beleid deze domeinen correct behandelt. Wees u bewust van mogelijke coderingsproblemen of inconsistenties in browsers.
• Cross-Origin Resource Sharing (CORS): CSP werkt samen met CORS. Als u cross-origin verzoeken doet, zorg er dan voor dat uw CORS-configuratie compatibel is met uw CSP-beleid.
• Regionale beveiligingsnormen: Sommige regio's hebben mogelijk specifieke beveiligingsnormen of -vereisten. Onderzoek en voldoe aan deze normen bij het implementeren van CSP voor gebruikers in die regio's.
• Culturele overwegingen: Houd rekening met culturele verschillen in hoe websites worden gebruikt en benaderd. Pas uw CSP-implementatie aan om potentiële beveiligingsrisico's aan te pakken die specifiek zijn voor bepaalde regio's of demografische groepen.
• Toegankelijkheid: Zorg ervoor dat uw CSP-implementatie de toegankelijkheid van uw website niet negatief beïnvloedt. Blokkeer bijvoorbeeld geen noodzakelijke scripts of stijlen die nodig zijn voor schermlezers of andere ondersteunende technologieën.
• Testen in verschillende regio's: Test uw CSP-implementatie grondig in verschillende geografische regio's en browsers om eventuele problemen te identificeren en op te lossen.

Probleemoplossing voor CSP

Het implementeren van CSP kan soms een uitdaging zijn en u kunt problemen tegenkomen. Hier zijn enkele veelvoorkomende problemen en hoe u ze kunt oplossen:

• Website werkt niet meer na het inschakelen van CSP: Dit wordt vaak veroorzaakt door een te restrictief beleid. Gebruik de ontwikkelaarstools van de browser om de bronnen te identificeren die worden geblokkeerd en pas uw beleid dienovereenkomstig aan.
• CSP-overtredingsrapporten worden niet ontvangen: Controleer uw serverconfiguratie om er zeker van te zijn dat het report-uri- (of `report-to`-) eindpunt correct is geconfigureerd en dat uw server POST-verzoeken correct afhandelt. Controleer ook of de browser de rapporten daadwerkelijk verzendt (u kunt de ontwikkelaarstools gebruiken om het netwerkverkeer te controleren).
• Moeilijkheden met inline scripts en stijlen: Als u problemen ondervindt met inline scripts en stijlen, overweeg dan om nonces of hashes te gebruiken om ze op een witte lijst te zetten. U kunt ook proberen de code naar externe bestanden te verplaatsen.
• Problemen met scripts van derden: Gebruik SRI om de integriteit van scripts van derden te verifiëren. Als u nog steeds problemen ondervindt, probeer dan de scripts lokaal te hosten of neem contact op met de externe provider voor hulp.
• Browsercompatibiliteitsproblemen: CSP wordt ondersteund door de meeste moderne browsers, maar er kunnen enkele compatibiliteitsproblemen zijn met oudere browsers. Test uw beleid in verschillende browsers om er zeker van te zijn dat het werkt zoals verwacht.
• Conflicten in CSP-beleid: Als u meerdere CSP-beleidsregels gebruikt (bijv. van verschillende plug-ins of extensies), kunnen deze met elkaar conflicteren. Probeer de plug-ins of extensies uit te schakelen om te zien of dat het probleem oplost.

Conclusie

Content Security Policy is een krachtig hulpmiddel om de beveiliging van uw website te verbeteren en uw gebruikers te beschermen tegen verschillende bedreigingen. Door CSP correct te implementeren en best practices te volgen, kunt u het risico op XSS-aanvallen, clickjacking en andere kwetsbaarheden aanzienlijk verminderen. Hoewel de implementatie van CSP complex kan zijn, zijn de voordelen op het gebied van beveiliging en gebruikersvertrouwen de moeite meer dan waard. Onthoud dat u moet beginnen met een strikt beleid, grondig moet testen en uw beleid voortdurend moet bewaken en verfijnen om ervoor te zorgen dat het effectief blijft. Naarmate het web evolueert en er nieuwe bedreigingen ontstaan, zal CSP een essentieel onderdeel blijven van een alomvattende webbeveiligingsstrategie.